# HP OpenView Service Desk

## version 4.5

## Rule Enhancements

February 2006

© Copyright 2006 Hewlett-Packard Development Company, L.P.

## Content:

Last-minute information
Introduction
Getting Started

## LAST-MINUTE INFORMATION

There is no last-minute information.

## INTRODUCTION

Service Desk has provided the possibility to define one single Database Rule (or UI Rule) that triggers for more than one event (such as when item is created and when item is deleted for Database Rule). Hence, rules with same conditions and actions can be combined into one which is easier to use.

Existing rules can be used without explicit migration operations. Existing compound rule trigger will be translated to multiple selection of single triggers automatically.

The validation of a Rule (e.g. a Database Rule when item is deleted cannot have update data action) will take all selected triggers into account.

## GETTING STARTED

### New UI and Database Rule Start Conditions

UI rules trigger when a certain event (such as when a form is opened or closed, or when the user enters data in a field) occurs in a form in the Service Desk client. Similarly, Database rules trigger on any event that changes an item in Service Desk (a new items is saved, an existing item is changed, or an item is deleted). Before Service Pack 18, UI rules and Database rules could only be triggered by a single event, as seen below:

Starting from Service Pack 18, it is possible to define multiple events that trigger a rule. This is shown in the following screenshots:

The possibility to define more than one event for the rule to respond to makes the rules easier to use. Before, actions that had to be undertaken as the result of multiple starting conditions (for example, a rule that fires when an items is opened and when it is updated) had to be implemented by multiple rules. Now, a single rule will suffice.

### About existing rules

Existing rules can be used without explicit migration operations.

Existing compound rule trigger will be translated to multiple selection of single triggers automatically.

Rule Type | Trigger Before Upgrade | Triggers After Upgrade
--- | --- | ---
UI Rule | After an item has been opened | Multiple selection:

- After new item has been opened
- After existing item has been opened

Database Rule | When item is created or modified | Multiple selection:

- When item is created
- When item is modified

### Validation of Rule Actions and Conditions

The actions available to a UI rule or a Database rule have always depended on the event that triggers the rule. For example, a Database rule that fires when an item is deleted cannot trigger an "Update data" action, because there is no data to update when an item is deleted. When multiple event types are chosen as trigger, only those actions are allowed that are available for each of the event types individually.
For example, the "Update data" action is not available for a Database rule that responds to event type "When item is deleted" but the "Command exec action" is available. When the event type "When item is created" is chosen as trigger of a Database rule, the "Update data" action as well as the "Command exec action" can be used both. Consequently, a trigger that responds to both "When item is deleted" as well as "When item is created" cannot invoke a "Update data" action, because only one of the two event types supports it. However, it can use a "Command exec action", because it is available for both event types.
Furthermore, some event types can be fine tuned with conditions. Conditions specify that in addition of the triggering event type, the field values of the currently open item should meet certain specified criteria. Some event types cannot depend on conditions. When an event type that can be triggered with a condition is used in combination with an event type that cannot accept a condition, it affects the way the rule is executed. When the event occurs to which conditions do not apply, Service Desk executes the action associated with the rule, without evaluating the condition, even though the condition is part of the rule.
For example, when you define a Database rule that triggers only on the event "When an item is deleted", the Database rule wizard will not show a conditions page. When you define a Database rule that triggers on the event "When an item is modified", you will have the option to specify conditions based on values of the item. When you are editing a Database rule that triggers both on "When an item is deleted" and "When an item is modified", you will see the conditions page. However, when the rule is executed, the conditions are not evaluated if the triggering event was "When an item is deleted". The occurrence of the triggering condition alone is in this case enough to execute the actions associated with the Database rule.
For this particular example, a warning in the Database rule wizard will bring this to the attention of the administrator:
Another example is when you define a UI rule triggers on the event "When a value has changed" or "After new item has been opened", it is possible to enable "Evaluate this rule when this field has been changed" for a rule condition. When the rule is being evaluated, this option is only effective for event "When a value has changed" and does not work for event "After new item has been opened". This is consistent with original UI Rule behavior.